Web services are typically implemented by a farm of web servers. A farm of web servers includes a number of web servers located at a single site. The servers in the farm communicate with one another to perform a set of operations for the service. Client computers make requests to the farm, and one of the servers in that farm picks up and responds to the request. In many services, especially secure services, the response or a portion of that response is provided as a portion of the next request to the service, such as to identify the client in subsequent requests, to indicate a state of the transaction, etc.
For example, a secure service needs to trust that the client computer that makes subsequent requests is the same client that was validated in a previous request. One way to accomplish this without validating the client with each request is to use information returned from the server in response to a previous request which is returned in a subsequent request, where information, such as the state of the transaction, is passed between the client and the server. Authentication of such information may be desired in subsequent requests, in addition to or in the alternative to authentication of the client. One approach to this is to package the data in a message, and place a Message Authentication Code (MAC) along with the data. Typically, the MAC is implemented using certain authentication algorithms. One example algorithm is Hash Message Authentication Code (HMAC). This approach uses a secret key log and the HMAC algorithm to generate a hash of data that is to create a MAC that is sent back to the client computer in the message. The client is required to provide this MAC back to the service when the client makes its next request. Through the use of the MAC feedback there is a strong presumption that the client has not modified, tampered or tried to create false data for the secondary request.
The problem with using keys in a web service is that a service often maintains multiple sites to provide the service. For example, the service could have a primary site in Los Angeles with a farm of servers providing the web service, but there could be another site in another city, such as Minneapolis, that can provide the same service. This other site is provided in the event there is a disaster in the city where the main service is located that causes the primary site to go down, or to handle overflow in the system. If the service desires to have an absolute 100% up time for its service, even in a worst case scenario where the primary site goes down, there is a possibility that the response to the first request from a client in this flow was handled by the primary site, and following the disaster the secondary request will be routed to the disaster recovery site or backup site. However, in this approach there is a problem maintaining synchronization of the keys between the two sites, because the keys are maintained on the primary site and not on the secondary site.
Moreover, when the service uses a farm of servers to provide the service, each server in that farm needs to have the keys as well. This creates an additional problem of synchronization between the servers at one site in addition to the synchronization problem when using multiple sites. The above synchronization is not a problem if the service does not rollover keys. By rolling over keys, the keys are replaced on a periodic basis to enhance security. When using keys for generating message authentication codes it is desirable that the key only works for a short period of time. In a typical web server the keys might be updated once a week to provide each server in the service with a list of keys, and each MAC created with this key may only be valid for a day after it is used. If the keys were permanently valid there would be no need to update them. However, because it is desirable to ensure that there is no opportunity to “hack” the system, keys are only valid for a certain period of time. Typically, the keys are valid for a time period that is significantly shorter than the time it would take someone to brute force hack the key. Using this approach by the time a hacker computes what the key was, the key has already rolled over and it is no longer valid. An additional problem of rollover is that when the keys are changed any messages that are out at client machines are invalidated immediately.